1. Technical Field of the Invention
This invention relates to computer programming. More particularly, it relates to establishing trust between software entities on a per-deployment basis.
2. Background Art
Websphere (WS) Information Integrator (II), an example of a pluggable architecture, provides an open pluggable architecture for obtaining identity mapping information for different systems involved in an integration project. This architecture allows both industry-standard integration components as well as proprietary elements to be integrated or plugged into WS II through a simple interface. The software components that can be plugged into WS II and work together with WS II are called Plugins.
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol that other programs use to look up information from a server. It is protocol for accessing information directories. LDAP is based on the standards contained within the X.500 standard, but is significantly simpler. And unlike X.500, LDAP supports TCP/IP, which is necessary for any type of Internet access. Because it's a simpler version of X.500, LDAP is sometimes called X.500-lite. LDAP should eventually make it possible for almost any application running on virtually any computer platform to obtain directory information, such as email addresses and public keys. Because LDAP is an open protocol, applications need not worry about the type of server hosting the directory.
LDAP servers index all the data in their entries, and “filters” may be used to select just the person or group desired, and return just the information desired. LDAP is used to look up encryption certificates, pointers to printers and other services on a network, and provide “single sign-on” where one password for a user is shared between many services. LDAP is appropriate for directory-like information, where fast lookups and less-frequent updates are the norm. LDAP also defines: (1) Permissions, set by the administrator to allow only certain people to access the LDAP database, and optionally keep certain data private, and (2) Schema, to describe the format and attributes of data in the server.
A plugin contains the logic to retrieve secured information from a LDAP server and then decrypt the secured information for WS II to use. A plugin is associated with a WS II instance, or deployment, and not associated with each user. This is an example of a situation where there is a need to build mutual trust between two software entities—in this example, WS II instance and a plugin invocation. Thus, there is a need not previously recognized or resolved by the art to establish mutual trust between the two software entities.
A further complication arises due to the fact that WS II trial versions can be freely downloaded off the web. Not only must the plugin know that it is talking to a WS II instance, but it needs to know that it is interacting with a specific customer-authorized deployment of WS II. Otherwise, a malicious user may install a trial version of WS II and try to get the plugin to divulge usernames and passwords to it. Therefore, there is a need not previously recognized or resolved by the art to establish mutual trust between the two software entities on a per-deployment basis, that is, with each deployment of WS II.
Applets run in a user's context (such as a browser or AppletViewer). They could be malicious, spreading viruses and so forth. The Java Virtual Machine (JVM) attempts to circumvent this problem by restricting the ability of applets to function. For example, unsigned applets are not permitted to read and write files, load libraries on a client, execute processes, exit the virtual machine, open network connections except to the host. Further, applets loaded over the net are passed through a verifier to ensure that bytecodes were not engineered. The trust issue in applets has heretofore required that applets be restricted to run in a closed sandbox thereby significantly curbing their abilities. Thus there is a need not previously recognized and resolved by the art for a trust mechanism that allows Plugins various privileges, including executing decryption logic embedded within it.
In Java, the problem of applets being too restrictive has heretofore been approached by allowing applets to be signed. A signed applet is one that is packaged within a signed jar file. The signed jar file can be downloaded from an HTTP server, just like any other jar file. However, for the applet to be trusted, the user must trust the key that was used to sign the jar file. When a signed applet is encountered, a security dialog pops up, identifying the signer of the jar. The user is given an option to either grant always, grant this session, deny, or provide more information to the applet. Once the user makes a selection, the applet will then run in the corresponding security context. However, this technique requires user intervention at least once, and it only establishes one-way trust. Mutual trust is not realized inasmuch as the signed applet is usable by anyone who can download it.
As a result, since applets are too restrictive, they are seldom useful. To allow more useful mobile code, ActiveX controls are used. These can be downloaded onto browsers or placed in a plugin directory. Since ActiveX controls do not run in a sandbox, they can run any commands on the user's system. The introduction of such controls spawned a variety of viruses on the Net. Consequently, validation of ActiveX is done by “code signing”, by which developers certify that their software modules are not harmful and pay a nominal fee to an agency for the privilege of obtaining a digital certificate. When an Activex control is downloaded to a browser, the browser checks to make sure there is a valid signature that has not been altered and that the developer is in good standing with the signature authority. Only then can the control be usable. While this approach is a solution to one-way trust, the ActiveX control is still unable to verify the authenticity of the caller.
Other approaches to trustworthiness include Microsoft Authenticode™ technology which lets end users who publish a software component verify that it was not changed since it was signed and downloaded. Although Authenticode technology provides some assurance of code identity and integrity, it does not establish mutual trust on a per deployment basis.
Thus, there is a need in the art for a system and method for establishing mutual trust between two software components on a per-deployment basis.